Feature: Throw TypeErrors in serialize/parse with .code
#163
Conversation
Minimal formatting as appropriate.
MaoShizhong
changed the title
serialize with .code
MaoShizhong
changed the title
serialize with .codeserialize/parse with .code
Passing a POJO is only compatible with Node v8.0+ For backwards compatibility, a custom callback has been passed instead. All tests now pass even with Node v0.8 and Mocha v2.5.3
|
Looks like asserting throws with a POJO was breaking backwards compatibility with the action runs. This change should hopefully be backwards compatible with the versions now. |
|
Could I get some guidance on exactly what needs fixing here for the action runs? I'm a little confused as to why some tests that passed last run now suddenly fail after only changing the indentation for one of the files (which understandably was causing some of the later Node version tests to fail) |
Ah, sorry yeah I should have been more clear. I don't think you need to fix this in this PR. I think we have been considering just dropping the coveralls stuff, but it is unclear what we want bigger picture. I don't want to block landing things on this kind of unrelated stuff, so what I was thinking is I would run these tests locally once to check, but I dont see anything which should break so I hope we could just skip the check and force re-run each test run since it got past that part. |
|
|
||
| if (!isDate(expires) || isNaN(expires.valueOf())) { | ||
| throw new TypeError('option expires is invalid'); | ||
| var expiresError = new TypeError('option expires is invalid') |
There was a problem hiding this comment.
allocating an error object when it's not needed incurs a small performance hit, due to the stack trace generation. The bigger the stack when this is generated, the bigger the hit. From microseconds to possibly miliseconds. Thats an edgecase, in the real world, but is still possible.
This is one of those instances where following Dont Repeat Yourself isn't worth the perf cost. We save a tiny amount of repetition, but at a performance cost.
|
Just want to clarify what the desired way forward would be. // src/index.ts:250
if (!cookieNameRegExp.test(name)) {
const nameError = new TypeError(`argument name is invalid: ${name}`);
nameError.code = 'ERR_INVALID_ARG_VALUE';
throw nameError;
}Though since we're now using TS, I'd need to handle Also perfectly happy to have this PR superceded by #208, that's not a problem by any means (might even be preferable - very limited bandwidth currently so if this can be resolved more efficiently in that PR then that'd be wonderful). |
This comment was marked as spam.
This comment was marked as spam.
As requested in #162 as a non-breaking change prior to a change of error messages for a future major release, standard Node error codes have been added to each of the
parseandserializefunctions' TypeError throws.This should allow for a period of migrating for library users to error-handling via the
.codeerror property, as opposed to the sole.messageproperty, before they change (potentially breaking).This PR
parseandserializeto test for the correct error message and error code.compare-error.jsserializesameSite test for non-string/true argument values..codeproperties with standard Node error codes to each error throw in both theparseandserializefunctions.